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20.  ABSTRACT 


A  language  suitable  for  system  specification  should  allow  a  specification  to 
be  based  on  a  cognitive  model  of  the  process  being  described.  In  part,  such  a 
language  can  be  obtained  by  properly  combining  certain  conceptual  abstractions 
of  data  models  with  reference  and  control  concepts  designed  for  programing 
languages.  Augmenting  the  resulting  language  with  formal  versions  of  several 
natural  language  constructs  further  decreases  the  cognitive  distance  between 
specifications  of  large  systems  and  the  modelled  world. 

Several  core  elements  of  such  a  specification  language  are  developed  in  this 
report.  Emphasis  is  placed  on  modes  of  expression,  such  as  declarative 
constraints  and  temporal  reference,  which  are  derived  from  natural  language 
but  are  not  available  in  existing  formal  languages. 
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I.  INTRODUCTION 

A  major  effort  is  under  way  within  computer  science  to  design  new  languages  that  will 
enhance  the  development  of  reliable  and  maintainable  software,  particularly  for  large 
applications.  Through  careful  structuring  [13]  and  encapsulation  [17]  of  information, 
some  new  programming  languages  permit  hierarchical  development  of  large  programs. 
Each  layer  of  the  hierarchy  Is  understandable  in  terms  of  properties  abstracted  from 
modules  In  the  lower  layers.  From  the  definitions  of  the  modules  at  the  base  of  the 
hierarchy,  a  compiler  can  (or  could)  produce  an  acceptable  implementation  of  the  entire 
system. 

Another  lino  of  development  has  been  a  search  for  languages  with  more  expressive 
power  than  Is  provided  in  programming  languages  [6,  9,  16].  The  designers  of  these 
sped fixation  languages  are  willing  to  forego  the  ability  to  have  their  specifications 
mechanically  compilable  into  (efficient)  implementations.  In  return,  they  hope  to  make  it 
easier  to  write  a  formal  specification  of  a  process  and,  more  important,  to  increase  the 

likelihood  that  the  process  specified  is  Indeed  the  one  desired.^ 

Balzer  and  Goldman  [2]  enumerate  several  language  principles  claimed  to  be  beneficial 
for  both  the  creation  and  maintenance  of  large  software  systems.  These  include  the 
requirement  that  a  specification  be  a  cognitive  model  of  the  process  being  specified.  In 
general,  a  software  system  Is  Intended  to  represent  the  activity  in  some  "ideal  world," 
which  may  be  an  abstraction  of  a  real-world  process,  a  purely  mental  conception  of  the 
desired  behavior,  or  a  combination  of  the  two.  We  hope  to  minimize  the  "translation 
distance"  from  this  ideal  world  to  its  formal  representation  by  permitting  that 
representation  to  model  directly  the  ideal  Insofar  as  possible.  This  should  Increase  our 
confidence  that  a  specification  In  fact  matches  the  Intended  Ideal. 

Maintenance  Involves,  as  its  first  step,  translating  changes  to  the  ideal  world  into 
corresponding  changes  to  the  specification.  If  the  specification  is  a  cognitive  model,  the 
amount  of  change  required  In  the  specification  should  be  comparable  to  the  amount  of 
change  In  tho  Ideal.  We  believe  that  most  maintenance  changes  represent  fairly  small 
chongos  to  the  ideal  world. 

A  good  source  of  Ideas  for  language  components  that  help  In  constructing  cognitive 
models  is  natural  language.  Natural  language  has  been  roundly  criticized  In  some  circles 
[12]  because  of  its  Informality  and  ambiguity.  Clearly  a  formal  language  cannot  adopt 
thnso  characteristics,  although  they  contribute  significantly  to  the  utility  of  natural 
languages  for  communication.  But  natural  languages  also  contain  a  variety  of  modes  of 
expression  that  are  richer  than  those  provided  by  even  the  highest  level  programming 
languages,  yet  that  have  readily  formalizable  counterparts.  A  number  of  these  are 
developed  In  this  report.  One  reason  for  their  absence  from  programming  languages  Is 
undoubtedly  the  difficulty  of  providing  for  (efficient)  computer  Implementation  of  their 


We  thir*  of  our  language  at  specification  oriented, 
a  transformational  development  [3). 


Our  goal  it  to  have  programs  produced  from  specifications  throu^s 
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amoral  use.  This  Is  not  a  restriction  on  natural  languages,  which  are  generally 
concerned  with  communicating  only  the  requisite  external  behavior  of  a  process.  The 
Implementation  of  that  process,  whether  on  a  computer  or  otherwise,  is  an  orthogonal 
concern. 

Since  the  pioneering  work  of  Codd  [8]  on  relational  data  bases,  several  distinct  data 
models  have  boon  developed  and  studied.  An  often  noted  characteristic  of  these  models 
Is  that  they  provide  not  only  the  basis  for  machine  storage  and  manipulation  of  data,  but 
a  cognitive  model  of  the  data  domain  as  well,  in  fact,  these  data  models  bear  great 
similarity  to  the  semantic  nets  used  in  artificial  intelligence  programs  for  understanding 
natural  language,  as  demonstrated  In  [15]. 

Tho  specification  language  described  below  is  based  on  such  a  data  model.  We 
believe  that  any  process  can,  and  should,  be  defined  In  terms  of  a  variety  of  entity  types, 
specific  to  tho  process,  which  are  associated  with  one  another  by  means  of  process 
specific  relations,  and  acted  upon  by  process  specific  actions.  These  actions  consist  of 
combinations  of  creation  and  destruction  operations  on  these  entities  and  associations. 

Section  2  of  this  report  develops  the  static  aspects  of  this  model.  It  presents  means 
for  specifying  the  structural  regularity  of  the  data  domain,  including  a  hierarchy  of  object 
types,  relations  on  those  types,  constraints  on  data  states,  and  derived  relationships 
(alternative  "views").  It  also  lays  out  a  powerful  query  language  for  expressing 
predicates  on  the  data  states  and  for  referring  to  objects  In  those  states.  Section  3 
introduces  the  moans  for  defining  the  dynamic  aspects  of  a  process.  These  mechanisms 
rely  on  the  underlying  data  model  to  define  a  number  of  rich  constructs  not  available  in 
even  very  high-level  programming  languages.  We  point  out  how  each  of  these 
corresponds  to  a  descriptive  capability  in  natural  language,  and  why  each  enhances  the 
specification  of  large  systems. 

Notation 

In  this  report,  meta-concepts  of  the  language  are  printed  within  angle  brackets  (<>). 
In  syntactic  templates,  braces  ({})  enclose  optional  elements,  and  ellipses  (...)  indicate 
allowable  repetition  of  the  preceding  constituent.  The  "reserved  words"  of  the  language 
are  underlined. 

Tho  report  uses  examples  drawn  from  an  Ideal  world  of  ships,  ports,  piers,  cargos,  etc. 
Within  the  examples  and  text  describing  them,  the  names  of  these  "types"  are  printed  In 
bold  lower  case.  Variable  and  parameter  names  are  printed  in  italicized  lower  case.  The 
names  of  relations  and  actions  are  printed  In  BOLD  UPPER  CASE.  Finally,  objects 
roforred  to  literally  are  printed  in  Mixed  Case  Italics. 


2  SPFCIFYINC  THE  DOMAIN  OF  A  PROCESS 

An  Ideal  world  Is  not  an  arbitrary  collection  of  objects  related  In  unstructured  ways. 
Rather,  the  objects  can  be  categorized  into  various  type  classifications.  There  are  only 
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certain  kinds  of  relationships  in  which  the  various  types  of  objects  may  participate. 
Neither  does  the  ideal  world  permit  arbitrary  combinations  of  these  objects  and 
relationships  to  coexist. 

It  Is  important  to  capture  the  structure  of  the  ideal  world  in  the  specification.  Doing 
this  actually  makes  it  easier  to  specify  the  process  taking  place  In  the  ideal  world.  Even 
more  important,  It  enhances  our  ability  to  alter  the  specification  so  that  it  conforms  to  a 
changed  ideal  world.  This  Is  the  source  of  our  ability  to  maintain  software  systems 
created  from  the  specification.  The  structure  of  the  ideal  world  is  specified  through  a 
variety  of  <declaration>  forms  described  in  the  following  sections. 


2.1  Objects  and  Types 

Tho  various  types  of  objects  in  the  ideal  world  are  named  in  type  declarations.  The 
simplest  type  declaration  simply  lists  the  names  of  various  types: 

tune  ship:  pier:  cargo:  slip:  crewmember  end  tupe 

A  name  so  declared  may  be  used  as  a  <type  identified  elsewhere.  Some  types  may  be 
subtypes  of  others;  this  is  declared  by  including  a  modifier  in  a  type  declaration: 

tune  oiltanker,  a  kind  of  ship  : 

officer,  a  kind  of  crewmember 
end  tune 

This  declaration  states  that  every  oiltanker  Is  also  a  ship.  Analogously,  It  makes  officer 
a  subtype  of  crewmember.  Although  the  collection  of  oiltankers  and  ships  may  change 
as  a  process  executes,  no  object  is  ever  on  oiltanker  but  not  a  ship.  There  is  no  need 
for  the  specification  to  include  manipulations  of  the  data  specifically  to  maintain  this 
Invariant;  It  is  ensured  by  the  declaration. 

Smith  and  Smith  [14]  have  pointed  out  many  of  the  virtues  of  having  such  type 
hierarchies  from  the  standpoint  of  database  design.  The  most  salient  advantages  in  a 
specification  language  are  that  any  relations  and  operations  defined  on  a  type  are 
automatically  defined  on  its  subtypes,  and  that  the  types  can  be  used  in  the  data 
manipulation  language  to  strengthen  predicates  in  a  natural  and  concise  manner. 

Wo  can  also  define  synonyms  for  types,  and  define  one  type  as  a  restriction  of 
another: 

tune  message,  -  string; 

latitude,  ■  integer  jn  range  1-90,90)  s 
longitude,  -  Integer  in  range  I -180,180) 
end  tune 

This  declaration  states  that  message  Is  a  synonym  for  the  predefined  type  string,  and 
that  latitude  and  longitude  are  particular  subranges  of  the  predefined  type  Integer. 

Sometimes  a  specification  must  refer  to  particular  Individual  objects.  These  can  be 
Introduced  when  their  types  are  declared. 

_ _ J 
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tunc  port,  o  (Seattle, Santa  Barbara I  end  time 

dnclaros  that  the  type  port  has  (at  least)  two  distinct  instances,  which  will  be  referred 
to  In  the  specification  by  the  literals  Seattle  and  Santa  Barbara,  whereas 

tune  grain,  a  k  i  nd  of  cargo,  =  (Corn,  Wheat}  : 

fuel,  a  k  ind  of  cargo,  -  (Oil,  Natural  Gas  I 
end  tune 

declares  grain  and  fuel  to  be  subtypes  of  cargo,  with  their  instances  totally  enumerated 
by  literals.  No  further  Instances  of  grain  or  fuel  may  be  defined  or  created. 


2.2  Relation* 

Our  conception  of  relations  corresponds  closely  to  that  seen  in  Chen's 

p 

entity-relationship  diagrams  [7].  A  relation  is  defined  to  have  some  number  of  roles, 
each  role  having  a  name  and  a  type.  At  any  stage  of  a  process,  each  relation  contains  a 
collection  of  tuples.  Each  tuple  in  a  relation  has  an  object  filling  each  of  Its  roles.  The 
object  filling  a  role  must  be  an  instance  of  that  role's  type.  The  role  types  thus  serve  to 
rostrlct  the  tuples  that  can  appear  In  a  relation. 

The  doclaration  of  an  n-ary  relation  has  the  form: 

relation  <relation  identifier:*  (<role> . <role>  ): 

_____  |  n 

•  •  • 

end  relat ion 

Each  <role>  Is  denoted  by  an  <ld:type>,  which  is  simply  an  arbitrary  name,  followed  by  a 
colon,  followed  by  a  type  lden“fler,  e.g.,  5 -.ship.  The  identifier  preceding  the  :  Is  the  role 
name,  and  the  type  Identifier  names  the  role  type.  By  convention,  a  type  name  t  alone 
con  bo  used  as  an  Id-.type  to  abbreviate  f:t,  and  a  name  of  the  form  t.d,  for  any  digit  d.  In 
ploco  of  t.d: t.  For  example,  jM/>.sblp  can  be  abbreviated  as  ship,  and  ship.hshlp  as 
ship  I. 

A  relation  PORTOFCALL  between  ships  and  ports  for  which  they  are  bound  and  a 
relation  SHIPPINGPIER  between  piers  and  the  cargos  that  they  handle  are  declared  by: 

re  I  of i on 

PORTOFCALLfjMp, port) ; 

SHIPPINGPIER  (cargo,  pier ) 

end  relation 

Unless  otherwise  specified,  a  relation  Is  many-to-many  (to-many  ...).  The  Ideal  world 
relationships  being  modeled  by  PORTOFCALL  and  SHIPPINGPIER  are  both  many-to-many. 


Unlike  Chen,  we  do  not  distinguish  between  inter-entity  relationships  and  values  of  attributes  of  entities.  We  believe 
this  distinction  belongs  m  the  realm  of  implementation,  not  specification,  being  based  on  the  usage  of  information  rather 
than  the  nature  of  the  information  itself. 
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Tho  concopt  of  a  key  of  a  relation  is  familiar  in  relational  data  bases,  and  is  important 
to  capture  In  a  specification.  One  or  more  keys  for  a  relation  can  be  specified  by  a 
modifier  on  the  relation  declaration.  Each  key  consists  of  one  or  more  role  names. 
Another  Important  concept  we  call  covering.  A  relation  covers  a  role  if  every  object  of 
that  role's  type  fills  that  role  in  at  least  one  tuple  in  the  relation.  If  a  relation  covers  a 
role  that  is  a  key  of  the  relation,  then  every  object  of  that  role's  type  fills  the  role  In 
exactly  one  tuple  in  the  relation.  In  this  case,  we  say  the  relation  defines  the  role. 

relation 

CAPACITY  i ship,  volume) ,  de  f  i  nes  ship; 

CONTAINS  (skip,  cargo,  volume) ,  keg  is  (ship, cargo) ; 

PIERPORTI/n'rr.^arf) ,  def  i nes  pier,  covers  port ; 

SLIPS  (pier,  slip) ,  def  ines  slip,  covers  pier ; 

BERTH(iA//>,  slip) ,  keg  i  s  skip,  slip 
end  relation 

Those  declarations  specify  that  every  ship  has  a  single  volume  as  its  CAPACITY,  that 
ships  CONTAIN  volumes  of  cargo,  but  a  given  ship  has  only  a  single  volume  of  a  given 
cargo  at  any  time,  every  pier  is  in  a  particular  port  and  every  port  has  at  least  one 
pier,  every  slip  is  at  a  particular  pier  and  every  pier  has  at  least  one  slip,  and  that 
BERTH  relates  subsets  of  ships  and  slips  in  a  one-to-one  correspondence.  Just  as  a 
role's  type  restricts  the  Individual  tuples  in  a  relation,  a  relation's  keys  and  coverings 
restrict  the  collection  of  tuples  in  the  relation. 


2.3  Expressions.  Patterns,  and  Predicates 

An  <expression>  Is  a  constituent  of  the  language  that  is  used  to  refer  to  objects.  The 
simplest  expression  Is  a  literal,  such  as  5000  or  Corn,  which  refers  to  the  same  object 
whorovor  It  is  used  In  a  specification.  The  referent  of  a  literal  is  fixed  for  all  time. 

A  <varlable>  is  a  name  that  may  be  used  as  an  expression.  The  referent  of  a  variable 
may  change  fr^m  one  use  to  another.  Each  variable  in  the  language  is  declared  as  the 
Identifier  In  .  :type,  and  the  referent  of  the  variable  must  always  be  an  instance  of 
tho  type  that  appeared  in  its  declaration. 

Expressions  may  be  combined  by  operators  and  function  names,  as  in  a  conventional 
programming  language,  to  produce  other  expressions.  But  any  expression,  no  matter  how 
complex,  is  only  a  means  for  referring  to  an  object;  it  does  not  specify  any  activity  that 
changes  objects  or  relationships. 

A  <pattern>  has  the  form 

crelation  ident i f ier> (<expression>j ,  ....  <express i on>n) 
where  the  named  relation  Is  n-ary.  A  pattern  matches  a  tuple  If  each  object  filling  a  role 


It  i*  occasionally  the  ease  that  a  role  serves  as  a  key  for  some  subtype  of  its  type,  but  not  tor  the  entire  type. 
Similarly,  a  relation  may  cover  a  role  for  some  subtype  of  the  role's  type.  It  is  possible  to  succinctly  declare  key, 
covering,  and  defining  roles  for  a  subtype  of  the  role's  type,  but  our  examples  will  not  require  the  capability. 
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In  the  tuplo  is  the  referent  of  the  corresponding  expression.^  The  correspondence  Is  the 
natural  positional  correspondence  between  expressions  In  the  pattern  and  roles  in  the 
relation  declaration. 

A  pattern  may  be  used  as  a  <predicate>.  The  pattern  Is  said  to  be  True,  or  to  hold,  In 
a  particular  data  state  If  the  named  relation  contains  any  tuple  that  matches  the 
pattern;  otherwise  It  is  said  to  be  False  In  that  state.  Also, 

<expression>  ■  <expression> 

Is  a  predicate  that  holds  if  and  only  if  the  expressions  have  a  common  referent.  Finally, 

<expression>  i sa  <type  identifier> 

holds  If  the  (some)  referent  of  <expression>  is  an  instance  of  the  named  type. 
Predicates  may  be  combined  with  the  logical  operators  A,  V,  and  =>  with  the  traditional 
meanings. 

Predicates  may  also  be  written  with  quantified  variables.  V<id:type>  <predicate> 
holds  In  a  given  data  state  if  <predicate>  holds  in  that  state  for  every  assignment  of  an 
existing  object  of  the  quantified  variable's  type  to  that  variable.  3<id:type>  <predicate> 
holds  If  there  exists  any  such  assignment  for  which  (predicate)  holds  For  example, 

3s:  ship,  v:  volume  (CONTAINS  (j,  Corn,  v)  a  PORTOFCALLU.Sraffte)  20k-Cubtc-Meters^ 

holds  if  there  exists  some  ship  bound  for  Seattle  and  some  volume  of  Corn  of  at  least 
20 k -Cubic- Meters  on  that  ship.  We  say  that  the  predicate  holds  for  the  assignment  of  that 
ship  and  volume  to  the  variables  j  and  v,  respectively. 

A  predicate  that  would  test  for  the  existence  of  any  olltanker  bound  for  Santa  Barbara 
could  be  written: 

3 ship  (PORTOFCALLI ship,  Santa  Barbara)  a  ship  i  sa  olltanker) 
or  more  naturally  as 

loi/tanker  POmOFCALL{oi/tanker,Santa  Barbara ) 
which  might  hold  for  several  distinct  assignments  of  oiltankers  to  the  variable  oiltanker. 

English  noun  phrases  are  a  very  rich  form  of  expression.  They  provide  the  power  to 
refer  to  objects  by  describing  them;  l.e.,  by  predicating  how  they  relate  to  other, 

0 

possibly  also  described,  objects:  e.g.,  "a  ship  containing  at  least  20000m  of  corn  and 
bound  for  Seattle."  Through  the  use  of  possessive  and  reflexive  pronouns,  the 
descriptions  can  even  refer  to  the  object  being  described:  "an  employee  who  manages 


^Aj  «v«  shall  see,  som*  e»prpssions  may  bp  non- deterministic,  having  multiple  referents.  A  pattern  matches  a  tuple 
provided  the  objects  tn  the  tuple  are  among  the  referents  of  the  corresponding  expressions. 

^Actually,  the  predicate  -*  could  not  be  used  to  compare  objects  of  type  volume  unless  an  ordering  on  volumes  was 
defined.  Such  orderings  are  not  covered  »n  this  report. 
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hlmsolf."®  This  richness  is  available  In  formalized  form  through  use  of  the  predicate-based 
expression-. 

[<id:type>  I  <predicate>] 

whom  <predicate>  may  use  the  variable  name  In  <id:type>  freely.  If 
3<ld:typo>  <predlcato>  holds  for  some  assignment  of  an  object  to  that  variable,  then 
thnt  object  Is  a  referent  of  the  expression.  Such  expressions,  like  their  English 
counterparts,  may  be  non-deterministic,  having  many  referents,  deterministic,  having 
exactly  one  referent,  or  anomalous,  having  no  referents/  Formally,  "a  ship  containing  at 
least  POOOOm  of  corn  and  bound  for  Seattle"  is  expressed: 

[j :shlp|CONTAlNS(i, Corn, [i':volume|p> 20k -Cubic-Meters])  A  PORTOFCALLfj.Searr/f’)]  (1) 

The  expression  [<id:type>)True],  which  refers  to  any  Instance  of  some  type,  may  be 
abbreviated  as  [<type  identifier)].  It  is  common  for  such  expressions  to  appear  in  a 
pattern  with  the  type  identifier  naming  the  type  of  the  role  in  which  the  expression 
appears.  In  that  case,  the  expression  may  simply  be  written  as  the  symbol  $.  Thus, 

PORTOFCALLI  [oiltanker] ,  Santa  Barbara I 

will  match  tuples  In  the  PORTOFCALL  relation  having  Santa  Barbara  in  the  port  role  and 
any  oiltanker  In  the  ship  role.  The  more  general  pattern 

PORTOFCALLI  [ship] , Santa  Barbara) 

would  allow  a  match  for  any  ship,  not  just  an  oiltanker,  and  could  be  written  simply  as: 
PORTOFCALLI*. Santa  Barbara) 

It  Is  also  common  to  find  predicate-based  expressions  In  which  all  uses  of  the 
distinguished  variable  In  the  predicate  are  In  roles  of  the  same  type  as  the  variable.  In 
this  case  tho  predicate  Itself,  written  with  the  symbol  *  replacing  the  variable,  may  be 
usod  os  on  expression.  For  instance, 

CONTAINS  I*.  Corn,  [v\  votumel  v>iOtons) )  a  PORTOFCALL  I*.  Seattle) 

Is  equivalent  to  ( 1 )  above. 


The  noun  phrase  also  derives  power  from  its  informality.  While  we  sometimes  use  a  fairly  explicit  verb  to  indicate  a 
relation  --  "the  captain  serving  on  the  ship"  --  it  i$  mure  common  to  condense  the  relation  to  a  vague  preposition  --  "the 
captain  of  the  ship"  --  or  to  simply  provide  a  syntachc  indication  that  some  relationship  exists  --  "the  ship’s  captain.” 

^The  collection  of  referents  depends  on  the  collection  of  tuples  in  the  data  base,  and  on  the  objects  assigned  to  any 
variables  used  freely  within  the  predicate, 

®This  is  distinct  from  the  pattern  PORTOFCAllfoiitanker.Santa  Barbara),  which  uses  oiltanker  freely.  This  pattern 
would  only  match  the  tuple  for  the  specific  oiltanker  that  was  the  referent  of  oiltanker. 
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2.4  Constraints 

We  have  seen  how  role  types  and  relation  keys  serve  to  constrain  the  tuples  and 
tuple  collections  that  can  coexist  in  a  relation.  There  may  also  be  constraints  in  the 
Ideal  world  which  correspond  to  tuples  and  collections  of  tuples  that  may  not  coexist  in 
the  data  base  as  a  whole.  A  declaration  of  the  form: 

constraint  <predicate>:  ...  <predicate>  end  constra i nt 

outlaws  any  data  state  In  which  any  of  the  predicates  holds.  The  constraint 

constraint  loiltanker  PORTOFCM.Hoiltanker,Santa  Barbara)  end  constraint 

prohibits  any  oiltanker  from  ever  having  Santa  Barbara  as  a  destination.  A  second 
constraint, 

constraint  3s:  ship  (CONTAINS  Is,  [fuel),*)  a  CONTAINSIj,  [grain],*))  £I&  constraint 

prohibits  the  mixing  of  fuel  with  grain  in  a  ship  at  any  one  time.  Thus,  for  Instance,  a  ship 
could  not  contain  both  Oil  and  Corn. 

The  essential  "meaning"  of  the  CAPACITY  relation  comes  from  Its  appearance  In  a 
constraint: 

constraint  3r:ship(Y!  I  CONTAINS  >  CAPACITY  (.?,*) )  end  constraint 

which  prohibits  the  sum  of  volumes  of  various  cargos  contained  In  a  ship  from  exceeding 
tho  capacity  of  the  ship. 

Constraints  restrict  the  data  states  that  a  process  may  legitimately  create.  They 
ploy  a  for  more  central  role  In  the  specification  language  than  they  do  in  database 
languages.  That  role  Is  described  in  section  3.7  below. 


2  5  Derived  Relationships 

It  Is  convenient  to  be  able  to  refer  to  relationships  that  are  derived  from  others.  For 
Instance,  a  port  "handles"  Oil  if  it  has  a  pier  at  which  Oil  can  be  loaded  and  unloaded.  It 
Is  Important  to  be  able  to  define  the  "handies"  relation  in  such  terms  and  to  use  it  in 
patterns  In  the  same  way  as  any  other  relation.  It  is  unacceptable  for  the  relationship  to 
bo  given  on  Independent  definition  and  manipulated  by  the  specified  process  in  such  a 
way  os  to  explicitly  maintain  Its  invariant  connection  to  other  relations.  This  Invariant 
should  bo  declared  explicitly  and  its  maintenance  ensured  by  that  declaration. 

Those  Invariants  are  defined  by  giving  the  relation  a  normal  declaration,  including  roles 
and  keys,  and  using  it  In  a  derivation  as  well. 

der i vat i on 

<der i  vat  i on  name> (< i d: type>j ,...,< i d:  type>n) 
antecedent  <predicate> 
conferment  <pattern>  s 
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In  any  process  state  for  which 

3< i d: type>| i d: type>n  <predica te> 

holds  for  some  assignment  to  the  variables  <ld:type>(,  the  tuple  corresponding  to 
<pnttorn>  for  that  assignment  Is  taken  as  being  implicit  In  the  data  base.  No  distinction 
Is  made  in  the  language  between  Implicit  and  explicit  relationships.® 

Tho  only  variables  that  may  appear  freely  in  <predicate>  or  <pattern>  are  the 
<ld:type>(.  Each  expression  in  <pattern>  must  be  deterministic.  This  ensures  that  the 

tuple  corresponding  to  <pattern>  for  any  particular  assignment  to  the  variables  Is  well 
dofinod. 

Derivations  can  be  used  to  define  the  relationships 

-  A  ship  is  moored  at  a  pier. 

-  A  ship  is  in  a  port. 

-  A  port  handles  a  cargo. 

relation  MOORAGE  {ship,  pier) ,  key  i  s  ship-, 

INPORT  (j hip,  port) ,  key  i  s  shipi 
HANDLES  ( port,  car  go) 
end  relation 
dnr i vat i on 
DMOORir^//),  pier,  si  ip) 

antecedent  BERTH  (ship,  slip)  a  SLIPS  [pier,  slip) 
consequent  MOORAGE  iship,  pier) ; 

DiNPirA//*,  port,  pier) 

antecedent  MOORAGE  (ship,  pier)  a  PIERPORT  (/tier,  porf) 
consequent  INPORT  is  hip,  port  I  j 

DH AND  (cargo,  port,  pier) 

antecedent  SHIPPINGPIER  (cargo,  pier)  a  PIERPORT ( pier,  port) 
consequent  HANDLES(/)orf,carjol 
end  der i vat i on 

Note  that  MOORAGE  is  given  a  derivation  In  terms  of  BERTH  and  SLIPS,  and  is  itself 
used  In  the  derivation  of  INPORT.  It  is  acceptable  for  a  relation  to  be  given  several 
Independent  derivations.  The  existence  of  a  derivation  rule  for  a  relation  does  not 
prohibit  the  direct  Insertion  of  tuples  in  that  relation  by  the  specification.  For  instance, 
when  arriving  at  a  port,  there  may  be  a  time  when  the  INPORT  relationship  holds  for  that 
ship  before  It  ever  Is  positioned  In  a  slip  at  a  pier. 


The  only  exception  to  this  concerns  deletion  of  tuples.  Any  attempt  to  delete  a  tuple  that  would  atilt  exist  implicitly 
following  the  deletion  is  considered  anomalous. 
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3.  SPECIFYING  THE  DYNAMICS  OF  A  PROCESS 

Tlio  purpose  of  writing  a  specification  Is  to  describe  formally  the  behavior  that  takes 
place  in  the  Ideal  world.  The  essence  of  this  behavior  is  the  sequential  change  in  the 
collection  of  objects  and  associations.  A  specification  language  <statement>  is  used  to 
define  a  transition  from  one  such  state  to  another.  The  transitions  are  ultimately 
composed  of  five  basic  data  transitions: 

-  Object  Creation  —  Seldom  are  the  literal  objects  named  in  the  static 
domain  model  the  only  objects  that  exist  in  the  ideal  world.  New  piers, 
ships,  and  even  ports  may  come  into  existence  as  part  of  the  process.  The 
creation  of  a  new  object  Is  specified  by  the  statement: 

create  <type> 

This  specifies  the  creation  of  an  entirely  new  instance  of  <type>,  distinct 
from  all  objects  currently  (or  previously)  existing. 

-  Object  Destruction  --  The  ideal  world  need  not  be  cumulative.  Sometimes 
objects  cease  to  exist.  The  statement 

destroy  <expression> 

specifies  the  destruction  of  <expression>'s  referent  and  of  all  tuples  In 
which  that  referent  appears. 

-  Tuple  Insertion  --  New  associations  ore  created  by  the  statement: 

i nser  t  <pattern> 

which  will  add  to  the  data  base  a  new  tuple  matching  <pattern>.  If  the 
tuple  to  be  added  already  holds,  the  insert  operation  causes  no  change. 

-  Tuple  Deletion  --  Associations  are  removed  by  the  statement: 

do  I ete  <pattern> 

which  will  remove  from  the  data  base  a  tuple  matching  <pattern>.  If  no 
tuple  in  the  database  matches  <pattern>,  the  delete  operation  causes  no 
change. 

-  Tuple  Update  —  A  change  of  the  object  filling  a  particular  role  in  a  tuple  is 
specified  by: 

update  <role-name>  j_n  <pattern>  t_o  <expression> 

which  changes  the  object  filling  the  Indicated  role  In  some  tuple  In  the 
database  matching  <pattern>  to  the  referent  of  <expresslon>.  More 
precisely,  the  semantics  of  update  are  those  of  a  delete  followed  by  an 
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Insert. ^  treated  as  a  single  database  change.  The  symbol  oldvalue  may 
bo  used  in  <oxpression>  to  reference  the  object  originally  filling  the  role 
being  updated. 

All  of  those  statements,  with  the  exception  of  create,  may  be  non-deterministic.  That 
Is,  clue  to  the  appearance  of  non-determinlstic  expressions  within  the  statements,  there 
may  bo  distinct  changes  to  the  data  base,  each  of  which  meets  the  semantic 
requirements  of  the  statement.  It  Is  occasionally  desirable  to  make  a  change  Involving 
not  Just  ono  of  the  objects  specified  non-doterministically,  but  all  of  them.  This  can  be 
specified  with  statements  dcstroyall,  insertall,  deleteall,  and  updateall.^  ^  Thus,  the 
salary  of  every  officer  could  be  Increased  by  5  percent  via: 

update.!  I  I  salary  _i_n  SALf  (officer) ,  II  to  1 . 05*0 I dva  I ue 


3.1  Control  Structures 

To  specify  a  process,  it  must  be  possible  to  state  under  what  conditions  and  In  what 
order  various  data  transitions  take  place.  Control  structures  are  the  means  for 
accomplishing  this.  The  control  structures  available  in  most  high-level  programming 
languages  are  also  useful  in  specifications.  In  this  report,  the  only  unconventional 
control  structure  Introduced  is  the  demon  (see  section  3.4).  Otherwise,  we  will  confine 
ourselves  to  sequencing,  conditionals,  and  iteration. 

Sequencing  Is  indicated  by  separating  successive  <statement>s  by  semicolons: 

<9tatement>:  ...  <statement> 

To  meet  the  syntactic  requirements  of  the  language,  It  Is  often  necessary  to  bracket 
a  sequence  of  <statement>s  so  that  it  may  be  used  as  a  single  <statement>: 

hog i n<s ta tement >:  ...  <statement>  end 

In  mathematics,  we  are  familiar  with  problem  descriptions  that  Include  statements  such 
os  "Let  x,  y,  and  z  be  numbers  such  that  P(x,y,z).  Then  ..."  This  provides  a  way  of 
Introducing  some  new  names,  specifying,  or  restricting,  the  values  to  which  they  refer, 
and  then  using  those  names  In  further  statements.  This  facility  Is  provided  for  with  the 
syntax: 

h<?q  i  n 

3 < id: type>, . . . ,  <  i  d:  type>  <predicate> » 

<statei»ent>{  ...  <statement> 

end 

If  <prodlcnto>  holds  for  some  assignment  to  the  variables,  then  the  variable  environment 


'^Thu  gives  update  a  meaning  both  whan  no  tupla  matches  <patterns  and  when  tha  altered  tuple  i*  identical  to  an 
e»ntmg  one. 

'  'There  are  not  limply  iteration!  making  a  imgle  traniifion  on  each  loop,  but  are  primitive  transitions,  as  described  in 
section  J.6. 
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In  effect  outside  this  block  Is  extended  accordingly.  The  <statement>s  are  then 
executed  .sequentially  In  the  extended  environment.  Since  the  <predlcate>  may  be  true 
for  many  distinct  extensions,  the  block  may  be  non-determlnlstlc.  If  there  Is  no 
assignment  satisfying  <predicate>,  the  block  Is  anomalous.1^ 

Conditionality  is  expressed  by  a  <statement>  with  the  conventional  syntax: 

i  f  <predicate>  1  then  <statement>^l  I e I se  <statement>2l 

which  has  the  meaning  of  <statement>j  If  <predicate>  holds  and  of  <statement>£ 
otherwise.  A  conditional  <expression>  is  specified  analogously: 

i  f  <predicate>  then  <express i on>^  e I se  <express ion>2 

Another  useful  capability  Is  to  have  a  conditional  <statement>  in  which  the  predicate 
contains  existentially  quantified  variables,  permitting  the  "then"  clause  to  refer  to  the 
assignment  that  satisfied  the  predicate.  In  a  conditional  <statement>  or  <expression> 
having  a  predicate  of  the  form: 

3< var i ab I e>, . . . , < var i ab I e>  <pred i cate> 

the  variable  environment  surrounding  the  conditional  Is  extended  for  the  "then"  clause  to 
Incorporate  the  portion  of  the  assignment  satisfying  the  predicate  for  the  existentially 
quantified  variables.  The  variable  environment  for  the  "else"  clause  is  that  in  effect 
around  the  conditional  itself.  For  example,  the  formal  representation  of  "If  there  Is  a  ship 
In  Santa  Barbara  containing  20000m3  of  grain,  schedule  it  to  stop  in  Seattle"  Is: 

'  f  3j A//>( IMPORT liA( /i. 5anla  Barbara)  a 

CONTAINS  [grain] ,  (y:  volume  I  y  >  20k-Cubic-Mtters) ) ) 
thnn  inser  t  PORTOFCAIU  skip,  Seattle  I 

Finally,  a  simple  but  power*  il  form  of  iteration  consists  of  doing  the  same  activity  In 
forty  variable  assignment  for  which  some  predicate  holds: 

n^rnvnr  <predicate>  do  <statement> 

specifies  doing  <statement)  In  rvrry  extended  assignment  for  which  <predlcate>  holds. 
The  extensions  are  determined,  as  in  the  case  of  conditionals,  by  the  leading 
existentially  quantified  variables  on  <predicate>.  The  order  of  assignments  In  which 
<stotement>  is  to  be  done  is  non-deterministic.  All  are  calculated  with  respect  to  the 
data  state  existing  prior  to  the  Initiation  of  the  iteration;  the  effects  of  <statement>  In 
one  environment  have  no  bearing  on  the  collection  of  assignments  used.  The  example 
above  may  bo  rewritten  to  send  all  ships  with  20000m3  of  grain  to  Seattle: 

llhnroypr 

( IMPORT f iAr/> ,  5<7nfa  Barbara)  a 

CONTAINS  (ship,  (grain) ,  [y:  volume ly  >  20k-Cubic-M tiers] ) ) 
do  i  ry-.or  t  PORTOFCAIU  ship,  Seattle)  • 


On*  ot  the  pow*M  of  English  is  that  M  rarely  forces  us  (o  introduce  “variable"  name*  like  x,  y,  and  i.  Unfortunately, 
thrt!  povv^r  Appr.vs  to  dorivo  *n  largo  part  from  th#  informal  aspect  of  tha  language. 
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3.2  Actions 

The  hnsic  specif ier-deflned  building  blocks  of  a  specification  ate  neftonj.  They  are  the 
analog  of  procedures  In  a  program.  An  action  Is  a  parameterized  <statement>  that 
expresses  some  data  transition,  or  sequence  of  transitions,  In  terms  of  Its  parameters. 
The  <statement>,  or  definition,  specifies  the  transltlon(s)  through  the  use  of  the  primitive 
dntnbnso  operations  and  invocations  of  other  actions.  An  action  Is  declared  by: 

action 

<action  identifier?  (<forma!  parameter?  ...  <formal  parameter?), 
dr  f  i n i  t  i on  otatement?; 

•  •  • 

end  a c t i on 

The  <actlon  identifier)  provides  a  name  for  the  action.  Each  <formal  parameter)  Is 
simply  an  <ld:type>.  The  variable  environment  for  {statement)  consists  of  the  {formal 
pnrnmetcr>s.  with  an  assignment  in  which  each  parameter  refers  to  the  object  used  as 
the  corresponding  actual  parameter  in  an  invocation. 

An  invocation  is  denoted  by: 

<action  i dent i f i er? (<express ion?,  ...  expression?) 

with  the  usual  positional  correspondence  of  <expression)s  in  the  invocation  to  the 
parameters  of  the  action.  The  referents  of  the  <expression)s  In  the  invocation 
environment  become  the  referents  of  the  corresponding  parameters  of  the  action  within 
Its  definition.  If  any  of  the  <expresslon)s  Is  anomalous,  then  the  Invocation  Is 
anomalous. 

Example 

One  activity  In  shipping  is  the  loading  of  a  given  volume  of  some  cargo  onto  a  ship. 
This  action  would  be  declared  by: 

action 

LOADSHIP  is  flip,  car  go,  inert  volume) , 
de  f i n i t i on 

i  f  CONTAINS(jft/>,  cargo,  •)  then 

upda  t e  volume  j_n  CONTAINS  (ship, cargo, t)  to  o  I  dva  I  ue+tner 
else  inser t  CONTAINS(jM/>,c«r£0,incr) 
end  action 

The  definition  of  LOADSHIP  Is  simply  to  Increment  the  volume  of  cargo  contained  by  ship 
by  an  amount  incr,  or  to  Insert  a  new  CONTAINS  tuple  If  ship  did  not  contain  any  cargo 


13  By  specifying  •  dafau/f  volume  for  CONTAINS  lo  bo  ■  literal  Ovo/ume  (the  additive  Identity  for  volumes),  the 
conditional  could  bo  roplacad  by  its  "then"  clausa.  Defaults  ara  not  discuasod  in  this  raport,  but  a f#  a  vatuablo 
specification  mocha nism.  Also,  tho  oporotor  ♦  could  not  he  usod  with  objects  of  typo  votumo  tattoos  givon  a  Suilablo 
definition  in  tho  specification. 
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Another  activity  is  the  movement  of  a  ship  to  a  pier,  which  must  happen  when  the  ship 
is  to  ho  loaded  or  unloaded.  We  shall  declare  the  action  by: 

ac  t i on 

MOVESHIPiiAi/),  pier) , 
definition 

i  f  MOORAGE  (ship,  pin)  then 

comment  no  movement  needed  end  commen t  e  I  se 
update  slip  j_n  BERTHIjAi/’.  i)  .to  SLIPS l pier, it) 

end  ac  t i on 

If  the  ship  Is  already  at  the  specified  pier,  then  MOVESHIP  does  nothing.  Otherwise,  It 
updates  the  BERTH  tuple  for  the  ship  to  indicate  that  it  is  at  some  slip  at  the  desired 
pier.  This  slip  is  specified  with  the  non-deterministic  pattern  expression  SLIPS(^i*r,*). 


3.3  Procedural  Requirements 

In  the  Ideal  world,  there  Is  not  only  regularity  in  the  state  of  data  relationships,  but  in 
the  realm  of  processing  as  well.  The  regularity  in  the  types  of  objects  on  which  a  given 
action  is  performed  Is  captured  by  the  typing  of  the  formal  parameters  of  an  action.  At 
any  point  in  a  process,  it  may  be  the  case  that  the  data  and  variable  assignments  must 
satisfy  some  predicate  for  the  execution  to  be  feasible.  This  can  be  specified  by 
Including  <requlrement>s  at  appropriate  points  in  the  control  structure: 

renu i re  <predicate> 

A  require  declaration  can  appear  wherever  a  statement  can  appear.  It  signifies  that  the 
predicate  must  be  true  at  the  point  in  execution  where  it  appears. 

Two  common  points  to  include  <requirenient>s  In  a  specification  are  at  the  initiation 
and  completion  of  actions.  These  have  been  singled  out  syntactically  and  may  be 
declared  ns  preconditions  and  postconditions  of  an  action,  rather  than  included  within  the 

action's  definition.^ 

It  is  sometimes  desirable  to  state  a  requirement  on  the  transition  achieved  by  an 

action,  rather  than  (or  in  addition  to)  requirements  on  the  initial  and  final  states.  This 

can  he  done  with  a  syntactic  means  In  the  postcondition.  Any  expression  or  predicate  In 

a  postcondition  preceded  by  the  marker  old  refers  to  Its  value  or  truth  In  the  data  state 

TV 

at  action  Initiation,  rather  than  termination. 

Example 

Suppose  the  action  MOVESHIP  defined  above  can,  In  the  ideal  world,  only  be  used  to 
movo  a  ship  to  a  pier  If  the  ship  is  already  In  the  port  containing  that  pier.  This  fact  Is 


«4 

Precondition  and  postconditions  may  refer  to  the  action's  operands  by  using  the  formal  parameter  names  as  free 
variables. 

15 

Section  3.5  describes  a  more  general  facility  for  releience  to  past  data  states. 
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captured  by  placing  a  precondition  on  the  action: 
action 

MOVE  SHIP  iship,  pier) , 

pr  ccond  i  t  i  on  INPORT  (ship,  PIERPORTIpi  er ,  a) ) , 
definition  . . . 
end  ac t i on 

Tho  requirement  that  cargo  can  only  be  loaded  onto  a  ship  if  it  Is  moored  at  a  pier 
which  handles  that  cargo  can  be  captured  by  a  precondition  on  the  action  LOADSHIP: 

ac  t i on 

LOADSHIP  (ship, cargo, incr:  volume) , 

pmconrii  t  ipn  3  pier  SHIPPINGPIER  (cargo,  pier)  a  MOORAGE  I  ship,  pier) , 
definition  . . . 
end  ac  t i on 

Occasionally  It  Is  necessary  for  a  port  to  deal  with  a  new  class  of  cargo.  This  may 
necessitate  a  major  shakeup  In  the  assignment  of  cargos  to  piers  in  that  port.  The 
action  that  makes  the  necessary  changes  might  need  to  take  many  factors  into  account, 
and  might  well  bo  expressed  best  with  some  non-determinism,  since  several 
rensslgnments  might  be  equally  acceptable.  However,  it  might  be  absolutely 
unacceptable  to  deassign  a  Natural  Gas  pier  (due  to  excessive  costs  or  government 
regulations).  Also,  the  reassignment  must  still  leave  all  originally  handled  cargos  still 
handled,  though  not  necessarily  at  the  same  pier. 

PC  t i on 

ADDC  ARGO  (cargo,  port) , 

pr  ornnd  i  t  i  on  -  HANDLES  (part,  cargo) , 
do  f i n i t i on  ...  , 

pn1-. t cond i  t  i on  Vfu'rr (old  SHIPPINGPIER) Natural  Gas,  pier)  »> 

SHIPPINGPIER  (Natural  Gas.  pier) )  , 

postcondi t ion  Vcargo  (oJ_d  HANDLES  ( port ,  cargo)  ->  HANDLES  (port,  cargo) ) 
end  ac  t i on 


3.4  Data  Triggered  Processing 

In  describing  a  process,  It  Is  convenient  to  be  able  to  make  statements  of  the  form 
"whenever  <trlgger>  Is  the  case,  do  <response>".  <trlgger>  Is  some  condition  on  the 
objects  being  manipulated  by  the  process  and,  perhaps,  on  the  control  state*  of  the 
process  as  well.  <response>  Is  Itself  a  process  to  be  performed  when  that  condition  Is 
mot. 

Since  all  Information  about  the  objects  Is  captured  in  the  data  base,  the  predicate 
Innguaqo  provides  a  natural  formalism  for  expressing  those  triggering  conditions 
dependent  on  object  associations  and  types. 

Such  i/rmans  have  been  permitted  In  various  Al  languages  [4,  5].  Since  these  are 
programming  languages,  rather  than  specification  languages,  they  have  severely 
restricted  the  expressive  power  permitted  In  the  trigger  condition.  As  e  result, 
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computations  triggered  by  complex  conditions  have  to  be  "programmed"  in  these 
lammngns,  spreading  pieces  of  the  condition  throughout  the  program.  In  a  specification, 
however,  the  full  power  of  the  predicate  language,  Including  typed  variables,  logical 
operators,  and  quantification,  can  be  permitted  in  the  trigger  without  sacrificing  any 
desirable  specification  properties. 

Syntactically,  <demon>s  may  be  declared: 

demon 

<denion  ident i f ier> (<demon  parameters  ...  <demon  parameter>), 
tr  i cider  <predicate>, 
re&ponse  <statement>; 

end  demon; 

The  <demon  identifer>  becomes  the  name  of  the  demon.  Each  <demon  parameter>  is  an 
<ld:typo>.  A  demon  specifies  that  whenever  a  single  database  transition  leaves  a  state 
In  which  the  predicate  holds  with  respect  to  some  assignment  to  the  demon  parameters, 
and  the  predicate  did  not  hold  for  that  assignment  In  the  pre-transition  state,  then 
<stntcment>  Is  to  be  executed,  In  the  post-transition  state,  for  that  assignment.  A 
single  transition  may  trigger  several  demons,  and  may  trigger  a  single  demon  with  several 
assignments.  In  this  case,  all  such  demons  are  to  have  their  responses  performed  for  all 
assignments,  but  the  order  In  which  this  is  to  happen  is  non-deterministic. 

On  occasion,  the  triggering  condition  for  a  demon  can  be  described  best  in  terms  of  a 
transition,  rather  than  in  terms  of  a  state,  e.g.,  "if  the  price  of  any  commodity  jumps  by 
over  7  percent,  ..."  To  express  such  demons,  the  symbol  old  may  be  used  lexically 
within  the  trigger  In  the  same  way  as  In  a  postcondition  (see  section  3.3). 

Example 

Supposo  the  shipping  system  receives  periodic  updates  on  the  progress  of  ships  at 
so  a,  In  the  form  of  latitude  and  longitude  readings  and  compass  headings.  Suppose  It 
also  receives  periodic  reports  on  weather  conditions  at  various  locations.  Finally, 
suppose  It  Is  capable  of  sending  messages  to  ships.  To  support  this  In  the  specification, 
the  domain  model  could  include: 

tune 

weather.  •  \Clear,  Stormy) ; 

heading,  ■  Integer  j_n  range  10,360 lj 

shiploc 

end  tune; 

relation 

WEATHERSTATUS(tAi/»/oc,  weather) ,  key  if,  shiploc ; 

SWPPOSiship,shiploc,heading) ,  key  j_s  ship,shiploc\ 

COORDINATES  i  shiploc,  latitude,  longitude) , 

defines  shiploc,  key  is,  {latitude, longitude) 

end  relation; 


action 
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BROADCAST  [ship,  message) .  definition  . . . 

end  act  ion; 

A  i lemon  can  specify  that  a  warning  is  to  be  sent  to  any  ship  approaching  a  stormy 
weather  area.  The  concept  of  "approaching"  must  of  course  be  formally  specified.  The 
details  of  this  are  really  orthogonal  to  the  issues  of  data-triggered  processes;  the  formal 
specification  would  define  a  many-to-many  relation  APPROACHIN Q(ship, shiploc)  and  a 
derivation  rule  defining  APPROACHING  In  terms  of  ship's  latitude,  longitude,  and  heading 
—  I.o. ,  In  terms  of  SHIPPOS  and  COORDINATES.  The  demon,  which  we  name 
STORMWARNING,  is  defined  by: 

demon 

STORMWARNING  {ship,  shiploc I . 

tr  i  tiger  WEATHERSTATUS  {shiploc.  Stormy)  a  APPROACHING  [ship,  shiploc) , 
response  BROADCAST  {ship,  "storm  at  latitude  "  •  COORDINATES  ( s  hiploc ,  ft ,  •) 

a  "  longitude  "  a  COORDINATES  i  s  hiploc,  t,*) ) 

end  demon; ^ 

Tho  trigger  of  this  demon  involves  two  relations,  APPROACHING  and 
WEATHERSTATUS,  which  change  as  the  process  executes.  It  Is  important  to  both  the 
rnliahility  and  maintainability  of  a  specification  that  this  behavior  be  stated  as  a 
cohesive  unit,  rather  than  distributed  in  the  various  places  In  the  process  where  It  comes 
Into  ploy. 


3.5  Temporal  Reference 

As  a  process  executes,  information  Is  being  produced  and  consumed.  In  writing  a 
program  to  perform  the  process,  a  programmer  must  be  concerned  with  the  storage 
space  required  to  hold  this  information.  Programs  manifest  this  concern  by  using 
compact  or  implicit  representations  of  information,  by  representing  only  that  information 
essential  to  correct  execution,  and,  most  pervasively,  by  releasing  space  used  to  store 
information  that  is  no  longer  needed.1  ^  In  a  specification  language,  however,  there  is  no 
reason  to  be  concerned  with  storage  space  as  a  finite  resource.  As  a  process 
executes,  the  current  collection  of  objects  and  associations  changes,  to  be  sure.  But 
the  history  of  execution  and  database  states  Is  conceptually  well  defined,  In  the  sense 
that  expressions  and  predicates  can  be  assigned  natural  meanings  with  respect  to  past 
times,  as  well  as  with  respect  to  the  current  state.1®  The  primitive  database  operations 
destroy,  delete,  and  update  are  not  destructive  operations  but,  like  Insert  and  create, 
alter  the  collection  of  current  objects  and/or  associations. 

'®The  operator  9  is  being  used  for  string  concatenation,  converting  numbers  to  strings  when  applied  to  numerical 
arguments. 

'^Programming  languages  include  facilities,  such  as  block  structure  and  garbage  collection,  which  help  the  programmer 
deal  with  this  storage  allocation  problem.  More  importantly,  as  we  shall  see,  programming  languages  simply  do  not 
provide  certain  rich  constructs,  whose  counterparts  are  available  in  natural  language,  that  would  make  the  storage 
allocation  problem  too  difficult  for  current  compiler  capabilities. 

18 The  execution  of  an  action  that  changes  a  previous  date  is  not  well  defined,  however;  we  leave  research  in  this 
area  to  the  producers  of  Star  Trek  and  adherents  to  certain  political  ideologies. 
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In  English.  wo  commonly  use  expressions  like  "the  President  at  the  end  of  the  Civil 
War"  nnd  "If  the  car  was  insured  at  the  time  of  the  accident  Syntactically, 

cex|'res9 i on>  a_t_  <temporal  reference? 

■^expression?  the  fore  I  af  terl  <tran3ition  reference? 

am  Ihnmsolves  <expresslon>s,  whose  values  are  the  objects  described  by  <expresslon> 
In  tho  roforoncod  state.  Similarly, 

<predicate?  a_t_  <temporal  reference? 

'■predicate?  tbe  fore  I  after!  <transition  reference? 

nrn  themselves  <predlcate>s.  A  <temporal  reference>  specifies  a  past  state  of  the 

1 9 

data  base,  and  Implicitly  the  execution  history  preceding  and  following  that  state.  It 
>lors  nor  indicate  a  lexical  point  in  the  specification,  and  thus  does  not  provide  access  to 
previous  bindings  of  specification  variables.  A  (transition  reference>  specifies  a 
particular  data  transition  In  the  process  history,  and  thus  the  before  and  after  states  of 
that  transition. 

The  value  of  temporal  reference  in  a  specification  is  that  it  enables  data  reference  to 
bo  localized  at  tbe  point  where  the  data  Is  needed.  In  a  language  permitting  reference 
to  ament  data  only,  it  becomes  necessary  to  introduce  auxiliary  concepts,  which  have 
no  analog  In  tho  ideal  world,  to  drag  historical  Information  through  the  execution  so  that  it 
will  be  an  rent  Information  at  the  point  of  consumption.  The  existence  of  a  global  data 
base,  changing  In  discrete  steps  and  representing  information  In  a  format  independent  of 
variable  bindings,  provides  the  opportunity  to  incorporate  temporal  reference  cleanly  into 
tho  specification  language. 

Example 

When  filling  a  customer's  order,  a  bill  must  be  sent  indicating  the  cost  for  that  order. 
Suppose  that  cost  Is  (In  part)  a  function  of  the  market  price  of  the  cargo  when  the  order 
was  placed,  which  may  differ  from  the  market  price  at  billing  time.  If  cargo  and  order  refer 
to  a  particular  cargo  and  order,  respectively,  then  the  expression 

MARMETPRtCEfougo,*)  before  crea t i on i order) 

20 

spoclflos  the  price  of  the  cargo  at  the  time  the  order  was  created. 


'  This  permits  temporal  references  to  be  built  up  in  expression-like  fashion. 

*°The  various  forms  for  (temporal  referenced  and  (transition  referenced,  such  as  creation(<exoression>),  have  not 
yet  been  delineated.  The  forms  appearing  here  are  only  meant  to  be  suggestive  of  actual  capabilities  and  syntax. 


FOR  PROCESS  SPECIFICATIONS 


19 


3.6  Process  Granularity 

Tho  domain  model  of  typed  objects  and  associations  has  a  "natural"  processing 
granularity.  The  primitive  transitions  at  this  level  are  insert,  delete,  update,  create,  and 
destroy.  The  ideal  process  being  specified,  however,  may  have  a  coarser  granularity. 
That  Is,  some  conceptually  Indivisible  state  transition  in  the  Ideal  can  only  be  described 
In  terms  of  multiple  primitive  transitions. 

Others  hove  recognized  that  the  granularity  differences  affect  the  checking  of 
Integrity  constraints  in  database  management  systems.  While  it  is  desirable  to  state  the 
Integrity  constraints  In  terms  of  states  of  the  Ideal  process,  they  may  be  violated  In  the 
spurious  Intermediate  states  that  exist  as  the  database  changes  from  the 
representation  of  one  Ideal  state  to  another.  Suppose,  for  example,  that  ship's  officers 
in  the  Ideal  process  could  be  reassigned  on  occasion  to  new  posts,  with  their  salaries 
changing  ns  part  of  the  reassignment  activity.  Suppose,  furthermore,  that  a  salary  floor 
exists  for  captains.  The  finer  grain  of  the  data  base  can  only  represent  a  reassignment 
os  a  sequence  of  primitive  operations.  If  the  reassignment  Is  specified  by  a  (update 
post;  update  salary)  sequence,  however,  the  salary  floor  constraint  may  be  violated 
temporarily  when  an  officer  is  being  upgraded  to  captain.  The  other  order  might  violate 
the  constraint  when  an  officer  was  being  demoted,  or  retired,  and  his  salary  reduced. 
Tho  resolution  of  this  problem  proposed  in  database  systems  Is  to  introduce  the  concept 
of  a  transaction,  or  structured  operation,  to  capture  the  granularity  of  the  ideal  process,  and 
to  have  the  system  guarantee  the  integrity  of  the  data  base  only  on  completion  of  these 
transactions,  but  not  within  them. 

The  same  Issue  must  be  faced  in  the  specification  language  because  the  domain 
constraints  and  demon  triggers  are  naturally  defined  with  respect  to  states  of  the  Ideal 
process.  But  even  in  the  absence  of  constraints  and  demons  in  a  specification,  it  is 
Important  to  capture  the  granularity  of  the  ideal  process  in  the  specified  process.  The 
primary  reason  for  this  is  the  enhancement  of  maintainability.  Adding  a  new  constraint  or 
demon  to  a  specification  with  the  wrong  granularity  will  not  yield  the  desired  new 
specification.  Furthermore,  specification  by  reference  to  past  states  of  a  process  (see 
section  3.5)  cannot  be  done  naturally  if  the  specified  granularity  is  not  matched  to  the 
Ideal. 

Rather  than  Indicating  when  (particular)  constraints  and  demons  are  to  be  checked, 
tho  specifier  should  define  Indivisible  database  transitions  matching  the  granularity  in  the 
Ideal  process.  The  resulting  specification  will  define  a  process  having  no  spurious 
Intermediate  states.  The  construction: 

atomic  <statement>j •  <statement>2»  •••  <statement>n  end  atomi c 

defines  an  Indivisible  "macro"  database  transition  as  the  composite  of  the  transitions 
defined  by  the  <statcment>,,  which  may  range  from  primitive  database  operations  to 
complex  control  structures  specifying,  perhaps  conditionally,  database  transitions.  The 
now  transition  defined  by  the  block  con  be  decomposed  Into  the  unordered  collection  of 
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primitive)  transitions  so  specified.  Since  no  intermediate  states  exist,  all  database 
conditionality  in  <statement>|  is  based  on  the  state  existing  at  the  start  of  the  atomic 

block,  and  is  independent  of  the  partial  transition  specified  by  <statement> j 
CstntomonOj _y  In  general,  this  makes  it  easier  to  specify  macro  transitions,  since  It  Is 
not  necessary  to  give  temporary  names  to  information  about  the  initial  state  that  may  be 
needed  to  compute  the  transition,  but  is  being  destroyed  by  the  transition. 


Example 

Suppose  the  data  base  includes  the  assignment  of  officers  to  ships,  and  the  salaries 
of  these  officers: 

time  assignment;  officer;  salary,  =  integer  in  range  UOOOO,  4000Q] ; 

position,  d  {Captain,  Firstmate) 
end  1 1  me ; 
relit  ion 

SAHof ficer,  salary) ,  clef  i  nes  of  ficer ; 

POST  [as si gnment,  position,  s hi p) ,  clef  i  nes  assignment ; 

FILLS  {assignment. of  ficer ) .  keg  i  s  assignments  f  ficer 
end  relation 

A  type  captain  could  be  defined  as  an  officer  filling  the  position  Captain  on  any  ship.  A 
constraint  can  declare  the  lower  bound  on  the  salaries  of  captains. 

tune 

captain.  -  i  Co;  officer!  3a:  assignment  FILLS  (a,  o)  n  PCST(a,Ca/>fain,t)]  I 

end  tune 

cons tr a i nt  SAL(  (captain!  ,*)  <  15000  end  constraint 

An  officer  o  could  be  transferred  to  a  new  assignment  a  by  the  action  REASSIGN,  which 
deletes  the  FILLS  tuple  Indicating  the  previous  officer  filling  a,  updates  the  FILLS  tuple 
for  o  to  Indicate  o's  new  assignment,  and  updates  the  SAL  tuple  for  o  to  indicate  a  new 
salary,  which  Is  some  function  FN  of  o's  previous  salary  and  the  salary  of  the  previous 
officer  filling  a. 

ac  t i on 

REASSIGN  (o:  of  ficer,  a:  ass  i  gnment ) ,  definition 
atom  i  c 

delete  FILLS(d,l); 

update  assignment  j_n  FILLS f S , o)  to  a; 

update  salary  j_n  SAL(o.l)  Uj  FNioldvalue,  SAL  (FILLS  (a,*)  ,*) ) 
end  atomic 
end  ac  t i on 

Tho  definition  of  REASSIGN  is  an  atomic  transition.  The  order  of  the  three  statements 
within  that  definition  is  Immaterial.  Constraints,  such  as  the  salary  floor  for  captains, 
must  not  be  violated  In  the  state  resulting  from  the  transition.  Because  this  Is  an  atomic 
transition,  the  argument  to  FN  Is  the  salary  of  the  previous  officer  filling  a. 
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Thu  collection  must  satisfy  certain  well-formedness  conditions  to  make  sense, 
insertion  of  a  new  association  involving  an  object  and  destruction  of  that  object. 


For  example,  it  cannot  include  both 
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It  mny  bo  argued  that  the  latter  effect  could  be  achieved  even  if  the  intermediate 
states  did  exist,  either  by  rearranging  the  order  of  operations  in  REASSIGN  or  by  saving 
the  salary  of  the  previous  officer  in  a  temporary.  There  are  good  reasons  not  to 
Introduce  such  implementations  of  the  transition  into  the  specification.  This  is  obvious  If 
a  somewhat  more  realistic  situation  is  considered.  In  general,  several  officers  may  be 
reassigned  or  retired  In  a  single  transition  in  the  ideal  world.  To  achieve  this  as  a 
sequence  of  state  transitions  would  require  either  a  sophisticated  ordering  of  the 
Individual  reassignmonts  or  saving  (potentially  large  amounts  of)  temporary  data  to 
overcome  the  Interdependencies  of  the  salaries.  Either  of  these  methods  would  obscure 
considerably  the  specification  of  a  data  transition  composed  of  a  collection  of  simpler 
transitions,  each  dependent  only  on  the  Initial  data  state.  The  atomic  construction 
permits  a  straightforward,  and,  thus,  less  error-prone,  specification. 


3.7  Constraints  and  Non-Determinism 

The  many  forms  of  declarative  information  introduced  in  the  preceding  sections  have 
been  constraining  In  nature.  They  serve  to  categorize  certain  database  states,  or  state 
transitions,  or  processing  sequences  as  anomalous.  The  function  of  constraints  in  data 
management  systems  has  been  seen  to  be  that  of  guaranteeing  the  integrity  of  the 
stored  data  [10,  11],  Any  attempt  to  violate  a  constraint  results  in  rejection  of  the  data¬ 
base  operation  that  would  cause  the  violation  (or,  In  some  simple  cases,  a  correction  of 
the  offending  value). 

Tills  uso  of  constraints  has  two  benefits.  Obviously  it  provides  a  great  deal  of 
protection  to  users,  whether  human  or  software,  of  the  data.  Furthermore,  It  opens  up 
the  potential  for  achieving  considerable  efficiency  in  a  compilation  process,  through  the 
choice  of  both  data  structures  and  algorithms  tailored  to  the  constrained  data  and 
constrained  use  thereof. 

However,  this  use  of  constraints  relegates  them  to  an  essentially  redundant  role  in 

specification.  That  is,  in  the  best  of  all  possible  worlds,  all  constraints  would  in  fact  be 
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Implied  by  the  process  specification  and  input  restrictions  alone.  In  other  words,  if 
Inputs  to  a  valid  implementation  of  our  ship  system  were  appropriate,  there  would  be  no 
execution  that  would  ever  "attempt"  to  overload  a  ship,  and  thus  the  capacity  constraint 
would  be  Implicit  In  the  specification. 

If  wo  look  at  natural  language,  however,  we  find  constraints  playing  a  more  active 

role.  It  Is  reasonable  to  say  "choose  a  ship  bound  for  Seattle  and  load  5000  tons  of 
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corn  onto  It."  It  "goes  without  saying"  that  the  non-determlnlstically  described  ship 
should  have  5000  tons  of  spare  capacity,  and  should  not  contain  any  Oil  or  Natural  Gas, 


^Although  it  mighl  be  very  difficult  to  express  certim  constraints  m  terms  of  constraints  on  input. 

^Throughout  th.s  section,  non-determmism  is  being  treated  only  as  a  way  of  indicating  a  range  of  alternatives,  any  ot 
which  acceptable.  An  implementation  of  the  specification  is  free  to  behave  m  any  of  the  acceptable  ways,  or  in 
different  acceptable  ways  at  d-fferent  times,  but  need  not  cover  all  the  alternatives  or  distribute  »ts  behavior  among  them 
m  any  particular  manner. 


A 
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since  those  cannot  be  combined  with  Corn.  In  reality,  it  Just  "goes  without  r^saying." 
Ilnvlnq  stated  the  constraints,  It  is  unnecessary  in  English  to  refine  every  descriptive 
rofnronco  to  the  point  where  the  only  objects  satisfying  the  description  are  those 
qunrnntood  to  be  "valid"  in  the  usage  context. 

Likewise,  It  is  undesirable  to  sprinkle  predicates  throughout  a  specification  solely  for 
the  purpose  of  a  voiding  a  conflict  between  the  declared  constraints  and  the  specified 
processing  To  do  so  would  destroy  the  locality  of  the  constraint  declaration,  not  to 

OA 

mention  the  great  burden  it  places  on  the  specifier.  Rather,  the  constraints  should 
affect  the  semantics  of  the  remainder  of  the  specification. 

Informally,  this  is  accomplished  by  viewing  the  alternatives  available  for  any 
non-dotorministic  construct  in  the  specification  as  being  limited  not  only  to  alternatives 
meeting  the  local  requirements  of  the  construct,  but  to  alternatives  permitting  the 
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process  to  be  completed  without  violation  of  any  constraint. 

More  formally,  possible  executions  of  a  specification  containing  non-deterministic 
constructs  can  be  viewed  as  forming  a  tree,  with  branches  corresponding  to  alternative 
continuations  of  the  process  (disregarding  constraints).  The  paths  leading  from  the  root 
of  tho  tree  to  certain  nodes  may  necessarily  violate  constraints  or  use  anomalous 
statements  in  reaching  that  node.  Label  all  such  nodes  anomalous.  Then 

1 .  Prune  away  all  subtrees  below  nodes  labeled  anomalous. 

2.  If  every  leaf  of  a  subtree  Is  labeled  anomalous,  label  the  root  of  the 
subtree  anomalous. 

Repent  steps  1  and  2  until  no  more  nodes  can  be  labeled.  Then  prune  away  each 
remaining  anomalous  node  and  the  branch  linking  it  to  its  parent.  If  no  tree  remains,  i.e., 
the  root  gets  labeled  anomalous,  then  the  specification  is  inconsistent.  Otherwise,  the 
remaining  tree  represents  the  subset  of  executions  actually  permitted  (specified), 
taking  constraints  Into  account.  It  Is  entirely  possible,  and  highly  likely  in  the  envisioned 
usage,  that  locally  non-determinlstic  constructs  turn  out  to  be  entirely  deterministic 
when  constraints  are  considered. 

Non-dctcrmlnlsm  comes  Into  a  specification  in  several  forms.  Predicates  formed  from 
patterns  with  unassigned  variables  used  freely  are  frequently  non-deterministlc,  as  are 
pattern-based  expressions.  It  is  also  possible  to  write  expressions  for  "any"  element  of 
n  set,  to  express  Iteration  over  elements  of  a  set  In  a  non-determlnistlc  (including 
arbitrary)  order,  and  to  express  a  collection  of  distinct  statements  as  alternative 
continuations  of  a  process. 


^Programmers  are  of  course  familiar  with  (hi*  burden,  for  they  are  generally  required  to  "compile  in"  constraints  when 
they  write  a  program. 

2S 

T he  use  of  constraint  here  is  to  be  taken,  very  generally,  to  include  not  only  Ihose  constraints  declared  in  the 
specification  but  also  the  use  of  anomalous  statements  and  the  universal  constraints  on  well-formed  manipulations  of  the 
data  base;  e.g,  "tnou  shall  not  create  and  destroy  the  same  object  in  a  primitive  transition." 
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Locnl  non-determinism,  constrained  away  by  global  considerations,  is  useful  for 
maintaining  locality  of  information  in  a  specification.  Where  true  non-determinism  exists 
In  the  ideal  world,  It  is  important  to  capture  the  full  range  of  acceptable  alternatives  In 
the  specification,  so  as  not  to  unwittingly  rule  out  efficient  implementations  by 
overconstrnlnlng. 

Example 

An  action  that  would  load  a  given  volume  of  some  cargo  from  one  port  onto  any 
available  ship  bound  for  another  specified  port  could  be  defined  by: 

action 

LOAD  {cargo,  volume,  port. I,  port. 2) , 
definition 
bcci  i  n 

J ship  POmOFCALLisfiip,  port.2)  s 
MOVESHIPIrAi/),  PIERPORT (#,  port.l)  s 
LOADSHIP!  cargo,  volume I 

end 

end  a c < i on 

Thn  definition  of  LOAD  Is  a  block  that  assigns  to  its  local  variable  ship  a  ship  having 
port  2  as  a  port  of  call.  Then  the  action  MOVESHIP  is  to  be  performed  on  that  ship, 
positioning  it  as  some  pier  In  port.l.  Finally,  the  cargo  is  actually  loaded  onto  the  ship. 

MOVESHIP  was  defined  earlier  as: 

ac  t i on 

MOVESHIP(.$Aj/>,  pier) . 

pr  econd  i  t  i  on  INPORT  Is  hip,  PIERPORT  ip  ie  r,*) )  , 
do  f i n i t i on 

i  f  MOORAGE  {ship,  pier)  then 

comment  no  movement  needed  end  comment  e  I  se 
update  slip  j_n  BERTH  I)  t_o  SLIPS  {pier, it) 

end  ac  t i on 

Considerable  use  has  been  made  of  the  interaction  between  constraints  and 
non-determinism.  The  predicate  used  to  assign  ship  required  only  that  the  ship  be  bound 
for  port. 2.  The  precondition  of  MOVESHIP  ensures  that  only  ships  in  port.l  can  be 
considered,  since  the  ship  is  to  be  moved  to  a  pier  In  port.l.  The  capacity  and 
Incompatible  cargo  constraints,  which  could  be  violated  by  LOADSHIP,  further  restrict  the 
choice  of  ships. 

The  pier  specified  in  the  invocation  of  MOVESHIP  is  also  non-deterministically 
specified  to  bo  any  pier  In  port.l.  However,  since  the  pier  selected  will  be  the  moorage 
of  the  ship  when  LOADSHIP  is  performed,  the  precondition  of  LOADSHIP  ensures  that 
only  a  pier  capable  of  handling  cargo  will  be  selected. 

Finally,  within  MOVESHIP,  the  slip  selected  (in  the  case  that  the  ship  really  needs  to 
bo  moved),  is  constrained  locally  only  to  being  any  slip  at  the  pier  to  which  the  ship  Is 
being  moved.  However,  since  ships  cannot  share  a  slip  (BERTH  is  a  1-1  relation),  only 
empty  slips  will  be  considered. 
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As  n  result,  the  constraints  semantically  "compile  themselves"  into  the  specification, 
restricting  the  ship,  pier,  and  slip  that  must  be  fixed  for  the  loading  operation.  A  given 
Invocation  of  LOADSHIP  may  be  non-deterministic,  deterministic,  or  even  anomalous. 


3.8  Anomaly  Control 

We  give  verbal  recognition  to  the  potential  anomaly  of  a  statement  In  English  by 
embedding  It  In  phrases  such  as  "Try  or  if  possible."  This  same  capability 

Oft 

belongs  In  specifications,  for  the  alternatives  are  intolerable.  This  situation  Is  distinct 
from  that  in  which  a  collection  of  equally  acceptable  statements  is  specified.  Contrast 
"Huy  four  artichokes  if  you  can;  otherwise  buy  two  pounds  of  peas"  with  "Buy  either  four 
artichokes  or  two  pounds  of  peas."  In  a  specification,  the  recognition  of  potential 
anomaly  is  dealt  with  by  the  construction: 

a 1 1 ewp t  <statement>j  s  otatement^: . . .  <statement>n  end 
which  has  the  semantics  of  the  first  <statement>|  which  Is  not  anomalous. 


4.  CONCLUSION 

This  report  has  focused  on  those  aspects  of  a  formal  process  specification  language 
that  rely  heavily  on  concepts  developed  out  of  Codd's  original  work  with  relational  data 
bases.  There  ore  a  number  of  other  aspects  to  the  language  that  embody  the  principles 
outlined  in  [2]. 

A  good  specification  language,  however,  will  not  eliminate  the  difficulties  in  software 
development.  It  will  simplify  the  mapping  from  "ideal  world"  to  formal  statement,  and  will 
ease  the  task  of  reflecting  changes  to  the  conception  of  that  world  in  its  formal 
counterpart.  Two  steps  remain  In  the  path  to  useful  computer  software. 

First,  a  specification,  as  presented  in  this  report,  defines  a  closed  world  of  activity 
responding  to  and  altering  Information.  It  is  necessary  to  split  this  closed  world  Into  a 
software  component  and  an  environment  to  adequately  specify  what  Is  to  be  implemented. 

Second,  the  mapping  from  a  specification  in  a  language  such  as  this  to  a  program  of 
acceptable  efficiency  will  rarely  fall  within  the  competence  of  existing,  or  even 
reasonably  foreseeable,  compilers.  Human  insight  remains  necessary.  One  approach  Is 
to  require  a  programmer  to  relate  his  program  to  the  specification  In  such  a  way  that  a 


’Thu  is  a  very  difficult  problem  in  programming.  If  the  condition*  making  an  activity  anomalous  can  bp  tested  at 
tuffir  mntiy  low  cost,  a  programmer  will  simply  embed  Ihe  activity  «  a  conditional,  essentially  hand  compiling  the 
constraints.  When  ihe  test  is  too  expensive,  or  the  programmer  cannot  oven  determine  what  an  adequate  test  is,  he  must 
resort  to  unconventional  control  mechanisms,  like  error  handling  or  backtracking. 
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computer,  perhaps  with  his  aid,  can  verify  its  validity  [17].  Another  approach  Is  for  the 
prorirammer  to  develop  the  implementation  by  sequentially  transforming  the  specification 
Into  an  acceptable  program,  with  each  step  in  the  transformation  sequence  being 
verified  (or  unvcrlfiahle  assumptions  recorded)  [3]. 

Not  all  the  richness  of  the  specification  language  comes  from  constructions  that 
prohibit  efficient  automatic  compilation,  however.  Many  of  the  uses  of  patterns,  type 
hierarchies,  and  typed  variables  appear  to  border  on,  or  fall  within,  the  capacity  of 
current  compiler  technology.  Data  management  languages  are  an  ideal  testing  ground  for 
those  ideas,  and  wo  feel  that  their  introduction  would  be  of  great  benefit  to  users  of 
such  languages. 

T ormally  specifying  a  large  system  cannot  be  made  an  easy  task,  no  matter  how  rich 
or  natural  a  language  we  provide.  Mechanical  aids  to  the  creation  of  formal 
specifications,  particularly  ones  permitting  use  of  some  of  the  power  of  informality  In 
natural  language  [1],  should  help,  but  ultimately  the  creation  of  good  specifications  is  an 
art.  For,  among  other  things,  a  good  specification  lends  Itself  to  simple  maintenance.  It 
Is  the  Insight  and  anticipation  of  the  human  who  creates  a  specification  that  gives  It  this 
property. 
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